Enterprises commonly maintain multiple copies of important data and expend large amounts of time and money to protect this data against losses due to disasters or catastrophes. In some storage systems, data is stored across numerous disks that are grouped together. These groups can be linked with arrays to form clusters having a large number of individual disks.
In cluster storage systems, data availability can be disrupted while arrays or groups of disks are being managed. For instance, it may be desirable to transfer access to disk groups from one array to another array. During this transfer, however, applications accessing data within the disk group can fail or timeout and cause a disruption to application service and operation of the enterprise. Such disruptions can also occur when arrays are added or removed from a cluster.
Regardless of the backup or data transfer techniques being used, enterprises can lose valuable time and money when storage arrays are taken offline or shutdown. In these situations, applications are shutdown, storage devices are disconnected and reconnected, logical unit numbers (LUNs) are re-mapped, etc. While the storage arrays are offline, operation of the enterprise is disrupted and jeopardized.
A host server may continue to perform data access operations to a backup or secondary storage controller in the event of a failure of a primary storage controller. For example, in the IBM HyperSwap™ configuration, a host server may access a primary and a secondary storage controller. The host server may direct all storage accesses to the primary storage controller and the two storage controllers may operate in concert to ensure that identical data is saved in both. HyperSwap software on the host server may be able to determine when the primary storage controller has failed and can automatically redirect all storage accesses to the secondary storage controller.
While all systems continue to perform without shutdowns or disruptions, the request for data may still be delayed due to the distance it must travel. In a hyperswap setup, host machines located at secondary sites access the disk systems at the primary site. This produces delays to the I/O operations due to the distance between sites. During a hyperswap (assuming a complete failure of the primary site), time is required on the secondary site host to switch the unit control blocks (UCBs) to the secondary disk.
Excess loads on cross-town data links can cause delays. As the amount of disk being mirrored increases, more cross-town bandwidth is needed, which increases costs. There is a need to reduce the load on the existing infrastructure. Problems can arise from a shortage of unit control blocks (UCBs) in metro mirror applications and the implementation of Parallel Access Volume (PAV) can use up the available addressing in the system. Making UCBs available can be time consuming and/or difficult. There remains a need to provide a simplified infrastructure configuration with a reduction in backlogs.